chore: merge docs repo into this repo#2526
Merged
tac0turtle merged 11 commits intomainfrom Aug 6, 2025
Merged
Conversation
Contributor
|
The latest Buf updates on your PR. Results from workflow CI and Release / buf-check (pull_request).
|
Contributor
|
Claude finished @tac0turtle's task —— View job PR Review: Merge Docs Repo + RebrandingI've conducted a comprehensive review of this large PR that merges the docs repository and rebrands from Rollkit to Evolve. Here's my feedback: ✅ Overall AssessmentThis is a well-executed merge and rebranding effort. The core code changes are consistent and logical, but several documentation and configuration issues need attention. 🔧 Code Quality & Best PracticesStrengths:
Areas for improvement:
🔒 Security ConcernsHigh Priority:
Medium Priority:
⚡ Performance ConsiderationsNo significant performance impact identified. The rebranding primarily affects:
🧪 Test Coverage ImpactConcerns:
Recommendations:
📚 Critical Documentation IssuesHigh Priority Fixes Needed:
Medium Priority:
🚀 Workflow & CI/CDIssues:
Recommendations:# Fix for build_docs.yml
permissions:
contents: read
# Pin action versions to commit hashes for security
- uses: peaceiris/actions-gh-pages@4f9cc6602d3f66b9c2b194ce8f2f06d8a46d6ac1 # v4📋 Action ItemsBefore merging:
Technical debt:
👍 ConclusionThis is a solid foundation for the monorepo structure. The core code changes are well-executed and maintain backward compatibility. The main issues are in documentation accuracy and security hardening - all fixable before merge. The rebranding effort shows good attention to detail in the core codebase, but needs completion in tests and documentation to maintain consistency. |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Summary of Changes
Hello @tac0turtle, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!
I've merged the separate documentation repository into this one, creating a monorepo. This change centralizes all project assets, making it significantly easier to keep the documentation updated alongside code changes. A major part of this effort involved a comprehensive rebranding, transitioning all mentions of 'Rollkit' to 'Evolve' or 'ev-node' across the entire codebase, including configuration, CLI tools, and internal logic. This streamlines development and ensures a consistent brand identity.
Highlights
- Comprehensive Rebranding: The project has undergone a comprehensive rebranding, with all instances of "Rollkit" being replaced by "Evolve" or "ev-node" across documentation, code comments, configuration files, and application descriptions. This includes updates in issue templates, contributing guides, READMEs, and various application-specific files.
- Documentation Monorepo Integration: The entire
docsrepository has been merged into this monorerepo, introducing a new documentation site built with VitePress. This integration includes new Vue components, configuration files, constants, and a complete set of learning guides, API documentation, and technical specifications, all reflecting the new "Evolve" branding. - Configuration and CLI Updates: Key configuration parameters and command-line flags have been updated to reflect the new branding, such as changing
rollkit.yamltoevolve.yamlandrollkit-testtoevolve-testfor chain IDs and config files. Dockerfiles and docker-compose configurations have also been adjusted to useev-nodeandevolve-datapaths and names. - Internal Code Refactoring and Consistency: Internal code logic, particularly within the
blockandpkg/storedirectories, has been updated to align with the rebranding. This includes renaming functions likeSetRollkitHeightToDAHeighttoSetSequencerHeightToDAHeightand updating metadata keys fromRollkitHeightToDAHeightKeytoHeightToDAHeightKey, ensuring consistency in data storage and retrieval. - External Integration and Testing Alignment: Client libraries (Rust) and E2E tests have been updated to reflect the new naming conventions and domain changes (e.g.,
rollkit.devtoev.xyz), ensuring that external integrations and testing environments are aligned with the new brand identity.
Using Gemini Code Assist
The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.
Invoking Gemini
You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.
| Feature | Command | Description |
|---|---|---|
| Code Review | /gemini review |
Performs a code review for the current pull request in its current state. |
| Pull Request Summary | /gemini summary |
Provides a summary of the current pull request in its current state. |
| Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in issue comments and review comments. |
| Help | /gemini help |
Displays a list of available commands. |
Customization
To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.
Limitations & Feedback
Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments or fill out our survey to provide feedback.
You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.
Footnotes
-
Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| - name: Build with VitePress | ||
| run: yarn build # or pnpm build / npm build | ||
| - name: Deploy to GitHub Pages | ||
| uses: peaceiris/actions-gh-pages@v4 |
Check warning
Code scanning / CodeQL
Unpinned tag for a non-immutable Action in workflow Medium
| run: BASE='/docs-preview/pr-${{ github.event.number }}/' yarn build | ||
|
|
||
| - name: Deploy preview | ||
| uses: rossjrw/pr-preview-action@v1 |
Check warning
Code scanning / CodeQL
Unpinned tag for a non-immutable Action in workflow Medium
…ain permissions Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
Contributor
There was a problem hiding this comment.
Code Review
This pull request merges the documentation repository and performs a large-scale rename from "Rollkit" to "Evolve"/"ev-node". The code changes for the rename are generally correct and consistent. However, the newly added documentation files contain several issues, including outdated links, incorrect flag names, and branding inconsistencies. I've provided specific comments to address these issues, with a focus on ensuring the documentation is accurate and up-to-date with the codebase changes.
Comment on lines
+75
to
+771
| `--home <path>` | ||
| *Example:* `--home /mnt/data/evolve_node` | ||
| *Default:* `~/.evolve` (or a directory derived from the application name if `defaultHome` is customized). | ||
| *Constant:* `FlagRootDir` | ||
|
|
||
| ### Database Path | ||
|
|
||
| **Description:** | ||
| The path, relative to the Root Directory, where the Evolve database will be stored. This database contains blockchain state, blocks, and other critical node data. | ||
|
|
||
| **YAML:** | ||
| Set this in your configuration file at the top level: | ||
|
|
||
| ```yaml | ||
| db_path: "data" | ||
| ``` | ||
|
|
||
| **Command-line Flag:** | ||
| `--evolve.db_path <path>` | ||
| *Example:* `--evolve.db_path "node_db"` | ||
| *Default:* `"data"` | ||
| *Constant:* `FlagDBPath` | ||
|
|
||
| ### Chain ID | ||
|
|
||
| **Description:** | ||
| The unique identifier for your chain. This ID is used to differentiate your network from others and is crucial for network communication and transaction validation. | ||
|
|
||
| **YAML:** | ||
| Set this in your configuration file at the top level: | ||
|
|
||
| ```yaml | ||
| chain_id: "my-evolve-chain" | ||
| ``` | ||
|
|
||
| **Command-line Flag:** | ||
| `--chain_id <string>` | ||
| *Example:* `--chain_id "super_rollup_testnet_v1"` | ||
| *Default:* `"evolve"` | ||
| *Constant:* `FlagChainID` | ||
|
|
||
| ## Node Configuration (`node`) | ||
|
|
||
| Settings related to the core behavior of the Evolve node, including its mode of operation and block production parameters. | ||
|
|
||
| **YAML Section:** | ||
|
|
||
| ```yaml | ||
| node: | ||
| # ... node configurations ... | ||
| ``` | ||
|
|
||
| ### Aggregator Mode | ||
|
|
||
| **Description:** | ||
| If true, the node runs in aggregator mode. Aggregators are responsible for producing blocks by collecting transactions, ordering them, and proposing them to the network. | ||
|
|
||
| **YAML:** | ||
|
|
||
| ```yaml | ||
| node: | ||
| aggregator: true | ||
| ``` | ||
|
|
||
| **Command-line Flag:** | ||
| `--evolve.node.aggregator` (boolean, presence enables it) | ||
| *Example:* `--evolve.node.aggregator` | ||
| *Default:* `false` | ||
| *Constant:* `FlagAggregator` | ||
|
|
||
| ### Light Client Mode | ||
|
|
||
| **Description:** | ||
| If true, the node runs in light client mode. Light clients rely on full nodes for block headers and state information, offering a lightweight way to interact with the chain without storing all data. | ||
|
|
||
| **YAML:** | ||
|
|
||
| ```yaml | ||
| node: | ||
| light: true | ||
| ``` | ||
|
|
||
| **Command-line Flag:** | ||
| `--evolve.node.light` (boolean, presence enables it) | ||
| *Example:* `--evolve.node.light` | ||
| *Default:* `false` | ||
| *Constant:* `FlagLight` | ||
|
|
||
| ### Block Time | ||
|
|
||
| **Description:** | ||
| The target time interval between consecutive blocks produced by an aggregator. This duration (e.g., "500ms", "1s", "5s") dictates the pace of block production. | ||
|
|
||
| **YAML:** | ||
|
|
||
| ```yaml | ||
| node: | ||
| block_time: "1s" | ||
| ``` | ||
|
|
||
| **Command-line Flag:** | ||
| `--evolve.node.block_time <duration>` | ||
| *Example:* `--evolve.node.block_time 2s` | ||
| *Default:* `"1s"` | ||
| *Constant:* `FlagBlockTime` | ||
|
|
||
| ### Maximum Pending Blocks | ||
|
|
||
| **Description:** | ||
| The maximum number of blocks that can be pending Data Availability (DA) submission. When this limit is reached, the aggregator pauses block production until some blocks are confirmed on the DA layer. Use 0 for no limit. This helps manage resource usage and DA layer capacity. | ||
|
|
||
| **YAML:** | ||
|
|
||
| ```yaml | ||
| node: | ||
| max_pending_blocks: 100 | ||
| ``` | ||
|
|
||
| **Command-line Flag:** | ||
| `--evolve.node.max_pending_blocks <uint64>` | ||
| *Example:* `--evolve.node.max_pending_blocks 50` | ||
| *Default:* `0` (no limit) | ||
| *Constant:* `FlagMaxPendingBlocks` | ||
|
|
||
| ### Lazy Mode (Lazy Aggregator) | ||
|
|
||
| **Description:** | ||
| Enables lazy aggregation mode. In this mode, blocks are produced only when new transactions are available in the mempool or after the `lazy_block_interval` has passed. This optimizes resource usage by avoiding the creation of empty blocks during periods of inactivity. | ||
|
|
||
| **YAML:** | ||
|
|
||
| ```yaml | ||
| node: | ||
| lazy_mode: true | ||
| ``` | ||
|
|
||
| **Command-line Flag:** | ||
| `--evolve.node.lazy_mode` (boolean, presence enables it) | ||
| *Example:* `--evolve.node.lazy_mode` | ||
| *Default:* `false` | ||
| *Constant:* `FlagLazyAggregator` | ||
|
|
||
| ### Lazy Block Interval | ||
|
|
||
| **Description:** | ||
| The maximum time interval between blocks when running in lazy aggregation mode (`lazy_mode`). This ensures that blocks are produced periodically even if there are no new transactions, keeping the chain active. This value is generally larger than `block_time`. | ||
|
|
||
| **YAML:** | ||
|
|
||
| ```yaml | ||
| node: | ||
| lazy_block_interval: "30s" | ||
| ``` | ||
|
|
||
| **Command-line Flag:** | ||
| `--evolve.node.lazy_block_interval <duration>` | ||
| *Example:* `--evolve.node.lazy_block_interval 1m` | ||
| *Default:* `"30s"` | ||
| *Constant:* `FlagLazyBlockTime` | ||
|
|
||
| ### Trusted Hash | ||
|
|
||
| **Description:** | ||
| The initial trusted hash used to bootstrap the header exchange service. This allows nodes to start synchronizing from a specific, trusted point in the chain history instead of from the genesis block. When provided, the node will fetch the corresponding header/block from peers using this hash. If not provided, the node attempts to sync from genesis. | ||
|
|
||
| **YAML:** | ||
|
|
||
| ```yaml | ||
| node: | ||
| trusted_hash: "YOUR_TRUSTED_HASH_HEX_STRING" | ||
| ``` | ||
|
|
||
| **Command-line Flag:** | ||
| `--evolve.node.trusted_hash <string>` | ||
| *Example:* `--evolve.node.trusted_hash ABCDEF012345...` | ||
| *Default:* `""` (empty, sync from genesis) | ||
| *Constant:* `FlagTrustedHash` | ||
|
|
||
| ## Data Availability Configuration (`da`) | ||
|
|
||
| Parameters for connecting and interacting with the Data Availability (DA) layer, which Evolve uses to publish block data. | ||
|
|
||
| **YAML Section:** | ||
|
|
||
| ```yaml | ||
| da: | ||
| # ... DA configurations ... | ||
| ``` | ||
|
|
||
| ### DA Service Address | ||
|
|
||
| **Description:** | ||
| The network address (host:port) of the Data Availability layer service. Evolve connects to this endpoint to submit and retrieve block data. | ||
|
|
||
| **YAML:** | ||
|
|
||
| ```yaml | ||
| da: | ||
| address: "localhost:26659" | ||
| ``` | ||
|
|
||
| **Command-line Flag:** | ||
| `--evolve.da.address <string>` | ||
| *Example:* `--evolve.da.address 192.168.1.100:26659` | ||
| *Default:* `""` (empty, must be configured if DA is used) | ||
| *Constant:* `FlagDAAddress` | ||
|
|
||
| ### DA Authentication Token | ||
|
|
||
| **Description:** | ||
| The authentication token required to interact with the DA layer service, if the service mandates authentication. | ||
|
|
||
| **YAML:** | ||
|
|
||
| ```yaml | ||
| da: | ||
| auth_token: "YOUR_DA_AUTH_TOKEN" | ||
| ``` | ||
|
|
||
| **Command-line Flag:** | ||
| `--evolve.da.auth_token <string>` | ||
| *Example:* `--evolve.da.auth_token mysecrettoken` | ||
| *Default:* `""` (empty) | ||
| *Constant:* `FlagDAAuthToken` | ||
|
|
||
| ### DA Gas Price | ||
|
|
||
| **Description:** | ||
| The gas price to use for transactions submitted to the DA layer. A value of -1 indicates automatic gas price determination (if supported by the DA layer). Higher values may lead to faster inclusion of data. | ||
|
|
||
| **YAML:** | ||
|
|
||
| ```yaml | ||
| da: | ||
| gas_price: 0.025 | ||
| ``` | ||
|
|
||
| **Command-line Flag:** | ||
| `--evolve.da.gas_price <float64>` | ||
| *Example:* `--evolve.da.gas_price 0.05` | ||
| *Default:* `-1` (automatic) | ||
| *Constant:* `FlagDAGasPrice` | ||
|
|
||
| ### DA Gas Multiplier | ||
|
|
||
| **Description:** | ||
| A multiplier applied to the gas price when retrying failed DA submissions. Values greater than 1 increase the gas price on retries, potentially improving the chances of successful inclusion. | ||
|
|
||
| **YAML:** | ||
|
|
||
| ```yaml | ||
| da: | ||
| gas_multiplier: 1.1 | ||
| ``` | ||
|
|
||
| **Command-line Flag:** | ||
| `--evolve.da.gas_multiplier <float64>` | ||
| *Example:* `--evolve.da.gas_multiplier 1.5` | ||
| *Default:* `1.0` (no multiplication) | ||
| *Constant:* `FlagDAGasMultiplier` | ||
|
|
||
| ### DA Submit Options | ||
|
|
||
| **Description:** | ||
| Additional options passed to the DA layer when submitting data. The format and meaning of these options depend on the specific DA implementation being used. | ||
|
|
||
| **YAML:** | ||
|
|
||
| ```yaml | ||
| da: | ||
| submit_options: "{"key":"value"}" # Example, format depends on DA layer | ||
| ``` | ||
|
|
||
| **Command-line Flag:** | ||
| `--evolve.da.submit_options <string>` | ||
| *Example:* `--evolve.da.submit_options '{"custom_param":true}'` | ||
| *Default:* `""` (empty) | ||
| *Constant:* `FlagDASubmitOptions` | ||
|
|
||
| ### DA Namespace | ||
|
|
||
| **Description:** | ||
| The namespace ID used when submitting blobs (block data) to the DA layer. This helps segregate data from different chains or applications on a shared DA layer. | ||
|
|
||
| **YAML:** | ||
|
|
||
| ```yaml | ||
| da: | ||
| namespace: "MY_UNIQUE_NAMESPACE_ID" | ||
| ``` | ||
|
|
||
| **Command-line Flag:** | ||
| `--evolve.da.namespace <string>` | ||
| *Example:* `--evolve.da.namespace 0x1234567890abcdef` | ||
| *Default:* `""` (empty, must be configured) | ||
| *Constant:* `FlagDANamespace` | ||
|
|
||
| ### DA Block Time | ||
|
|
||
| **Description:** | ||
| The average block time of the Data Availability chain (specified as a duration string, e.g., "15s", "1m"). This value influences: | ||
|
|
||
| - The frequency of DA layer syncing. | ||
| - The maximum backoff time for retrying DA submissions. | ||
| - Calculation of transaction expiration when multiplied by `mempool_ttl`. | ||
|
|
||
| **YAML:** | ||
|
|
||
| ```yaml | ||
| da: | ||
| block_time: "6s" | ||
| ``` | ||
|
|
||
| **Command-line Flag:** | ||
| `--evolve.da.block_time <duration>` | ||
| *Example:* `--evolve.da.block_time 12s` | ||
| *Default:* `"6s"` | ||
| *Constant:* `FlagDABlockTime` | ||
|
|
||
| ### DA Start Height | ||
|
|
||
| **Description:** | ||
| The block height on the DA layer from which Evolve should begin syncing. This is useful when deploying a new chain on an existing DA chain, allowing it to ignore historical data before its inception. | ||
|
|
||
| **YAML:** | ||
|
|
||
| ```yaml | ||
| da: | ||
| start_height: 100000 | ||
| ``` | ||
|
|
||
| **Command-line Flag:** | ||
| `--evolve.da.start_height <uint64>` | ||
| *Example:* `--evolve.da.start_height 500000` | ||
| *Default:* `0` (sync from the beginning) | ||
| *Constant:* `FlagDAStartHeight` | ||
|
|
||
| ### DA Mempool TTL | ||
|
|
||
| **Description:** | ||
| The number of DA blocks after which a transaction submitted to the DA layer is considered expired and potentially dropped from the DA layer's mempool. This also controls the retry backoff timing for DA submissions. | ||
|
|
||
| **YAML:** | ||
|
|
||
| ```yaml | ||
| da: | ||
| mempool_ttl: 20 | ||
| ``` | ||
|
|
||
| **Command-line Flag:** | ||
| `--evolve.da.mempool_ttl <uint64>` | ||
| *Example:* `--evolve.da.mempool_ttl 30` | ||
| *Default:* `20` | ||
| *Constant:* `FlagDAMempoolTTL` | ||
|
|
||
| ## P2P Configuration (`p2p`) | ||
|
|
||
| Settings for peer-to-peer networking, enabling nodes to discover each other, exchange blocks, and share transactions. | ||
|
|
||
| **YAML Section:** | ||
|
|
||
| ```yaml | ||
| p2p: | ||
| # ... P2P configurations ... | ||
| ``` | ||
|
|
||
| ### P2P Listen Address | ||
|
|
||
| **Description:** | ||
| The network address (host:port) on which the Evolve node will listen for incoming P2P connections from other nodes. | ||
|
|
||
| **YAML:** | ||
|
|
||
| ```yaml | ||
| p2p: | ||
| listen_address: "0.0.0.0:7676" | ||
| ``` | ||
|
|
||
| **Command-line Flag:** | ||
| `--evolve.p2p.listen_address <string>` | ||
| *Example:* `--evolve.p2p.listen_address /ip4/127.0.0.1/tcp/26656` | ||
| *Default:* `"/ip4/0.0.0.0/tcp/7676"` | ||
| *Constant:* `FlagP2PListenAddress` | ||
|
|
||
| ### P2P Peers | ||
|
|
||
| **Description:** | ||
| A comma-separated list of peer addresses (e.g., multiaddresses) that the node will attempt to connect to for bootstrapping its P2P connections. These are often referred to as seed nodes. | ||
|
|
||
| **YAML:** | ||
|
|
||
| ```yaml | ||
| p2p: | ||
| peers: "/ip4/some_peer_ip/tcp/7676/p2p/PEER_ID1,/ip4/another_peer_ip/tcp/7676/p2p/PEER_ID2" | ||
| ``` | ||
|
|
||
| **Command-line Flag:** | ||
| `--evolve.p2p.peers <string>` | ||
| *Example:* `--evolve.p2p.peers /dns4/seed.example.com/tcp/26656/p2p/12D3KooW...` | ||
| *Default:* `""` (empty) | ||
| *Constant:* `FlagP2PPeers` | ||
|
|
||
| ### P2P Blocked Peers | ||
|
|
||
| **Description:** | ||
| A comma-separated list of peer IDs that the node should block from connecting. This can be used to prevent connections from known malicious or problematic peers. | ||
|
|
||
| **YAML:** | ||
|
|
||
| ```yaml | ||
| p2p: | ||
| blocked_peers: "PEER_ID_TO_BLOCK1,PEER_ID_TO_BLOCK2" | ||
| ``` | ||
|
|
||
| **Command-line Flag:** | ||
| `--evolve.p2p.blocked_peers <string>` | ||
| *Example:* `--evolve.p2p.blocked_peers 12D3KooW...,12D3KooX...` | ||
| *Default:* `""` (empty) | ||
| *Constant:* `FlagP2PBlockedPeers` | ||
|
|
||
| ### P2P Allowed Peers | ||
|
|
||
| **Description:** | ||
| A comma-separated list of peer IDs that the node should exclusively allow connections from. If this list is non-empty, only peers in this list will be able to connect. | ||
|
|
||
| **YAML:** | ||
|
|
||
| ```yaml | ||
| p2p: | ||
| allowed_peers: "PEER_ID_TO_ALLOW1,PEER_ID_TO_ALLOW2" | ||
| ``` | ||
|
|
||
| **Command-line Flag:** | ||
| `--evolve.p2p.allowed_peers <string>` | ||
| *Example:* `--evolve.p2p.allowed_peers 12D3KooY...,12D3KooZ...` | ||
| *Default:* `""` (empty, allow all unless blocked) | ||
| *Constant:* `FlagP2PAllowedPeers` | ||
|
|
||
| ## RPC Configuration (`rpc`) | ||
|
|
||
| Settings for the Remote Procedure Call (RPC) server, which allows clients and applications to interact with the Evolve node. | ||
|
|
||
| **YAML Section:** | ||
|
|
||
| ```yaml | ||
| rpc: | ||
| # ... RPC configurations ... | ||
| ``` | ||
|
|
||
| ### RPC Server Address | ||
|
|
||
| **Description:** | ||
| The network address (host:port) to which the RPC server will bind and listen for incoming requests. | ||
|
|
||
| **YAML:** | ||
|
|
||
| ```yaml | ||
| rpc: | ||
| address: "127.0.0.1:7331" | ||
| ``` | ||
|
|
||
| **Command-line Flag:** | ||
| `--evolve.rpc.address <string>` | ||
| *Example:* `--evolve.rpc.address 0.0.0.0:26657` | ||
| *Default:* `"127.0.0.1:7331"` | ||
| *Constant:* `FlagRPCAddress` | ||
|
|
||
| ## Instrumentation Configuration (`instrumentation`) | ||
|
|
||
| Settings for enabling and configuring metrics and profiling endpoints, useful for monitoring node performance and debugging. | ||
|
|
||
| **YAML Section:** | ||
|
|
||
| ```yaml | ||
| instrumentation: | ||
| # ... instrumentation configurations ... | ||
| ``` | ||
|
|
||
| ### Enable Prometheus Metrics | ||
|
|
||
| **Description:** | ||
| If true, enables the Prometheus metrics endpoint, allowing Prometheus to scrape operational data from the Evolve node. | ||
|
|
||
| **YAML:** | ||
|
|
||
| ```yaml | ||
| instrumentation: | ||
| prometheus: true | ||
| ``` | ||
|
|
||
| **Command-line Flag:** | ||
| `--evolve.instrumentation.prometheus` (boolean, presence enables it) | ||
| *Example:* `--evolve.instrumentation.prometheus` | ||
| *Default:* `false` | ||
| *Constant:* `FlagPrometheus` | ||
|
|
||
| ### Prometheus Listen Address | ||
|
|
||
| **Description:** | ||
| The network address (host:port) where the Prometheus metrics server will listen for scraping requests. | ||
|
|
||
| See [Metrics](/guides/metrics.md) for more details on what metrics are exposed. | ||
|
|
||
| **YAML:** | ||
|
|
||
| ```yaml | ||
| instrumentation: | ||
| prometheus_listen_addr: ":2112" | ||
| ``` | ||
|
|
||
| **Command-line Flag:** | ||
| `--evolve.instrumentation.prometheus_listen_addr <string>` | ||
| *Example:* `--evolve.instrumentation.prometheus_listen_addr 0.0.0.0:9090` | ||
| *Default:* `":2112"` | ||
| *Constant:* `FlagPrometheusListenAddr` | ||
|
|
||
| ### Maximum Open Connections | ||
|
|
||
| **Description:** | ||
| The maximum number of simultaneous connections allowed for the metrics server (e.g., Prometheus endpoint). | ||
|
|
||
| **YAML:** | ||
|
|
||
| ```yaml | ||
| instrumentation: | ||
| max_open_connections: 100 | ||
| ``` | ||
|
|
||
| **Command-line Flag:** | ||
| `--evolve.instrumentation.max_open_connections <int>` | ||
| *Example:* `--evolve.instrumentation.max_open_connections 50` | ||
| *Default:* (Refer to `DefaultInstrumentationConfig()` in code, typically a reasonable number like 100) | ||
| *Constant:* `FlagMaxOpenConnections` | ||
|
|
||
| ### Enable Pprof Profiling | ||
|
|
||
| **Description:** | ||
| If true, enables the pprof HTTP endpoint, which provides runtime profiling data for debugging performance issues. Accessing these endpoints can help diagnose CPU and memory usage. | ||
|
|
||
| **YAML:** | ||
|
|
||
| ```yaml | ||
| instrumentation: | ||
| pprof: true | ||
| ``` | ||
|
|
||
| **Command-line Flag:** | ||
| `--evolve.instrumentation.pprof` (boolean, presence enables it) | ||
| *Example:* `--evolve.instrumentation.pprof` | ||
| *Default:* `false` | ||
| *Constant:* `FlagPprof` | ||
|
|
||
| ### Pprof Listen Address | ||
|
|
||
| **Description:** | ||
| The network address (host:port) where the pprof HTTP server will listen for profiling requests. | ||
|
|
||
| **YAML:** | ||
|
|
||
| ```yaml | ||
| instrumentation: | ||
| pprof_listen_addr: "localhost:6060" | ||
| ``` | ||
|
|
||
| **Command-line Flag:** | ||
| `--evolve.instrumentation.pprof_listen_addr <string>` | ||
| *Example:* `--evolve.instrumentation.pprof_listen_addr 0.0.0.0:6061` | ||
| *Default:* `"localhost:6060"` | ||
| *Constant:* `FlagPprofListenAddr` | ||
|
|
||
| ## Logging Configuration (`log`) | ||
|
|
||
| Settings that control the verbosity and format of log output from the Evolve node. These are typically set via global flags. | ||
|
|
||
| **YAML Section:** | ||
|
|
||
| ```yaml | ||
| log: | ||
| # ... logging configurations ... | ||
| ``` | ||
|
|
||
| ### Log Level | ||
|
|
||
| **Description:** | ||
| Sets the minimum severity level for log messages to be displayed. Common levels include `debug`, `info`, `warn`, `error`. | ||
|
|
||
| **YAML:** | ||
|
|
||
| ```yaml | ||
| log: | ||
| level: "info" | ||
| ``` | ||
|
|
||
| **Command-line Flag:** | ||
| `--log.level <string>` (Note: some applications might use a different flag name like `--log_level`) | ||
| *Example:* `--log.level debug` | ||
| *Default:* `"info"` | ||
| *Constant:* `FlagLogLevel` (value: "evolve.log.level", but often overridden by global app flags) | ||
|
|
||
| ### Log Format | ||
|
|
||
| **Description:** | ||
| Sets the format for log output. Common formats include `text` (human-readable) and `json` (structured, machine-readable). | ||
|
|
||
| **YAML:** | ||
|
|
||
| ```yaml | ||
| log: | ||
| format: "text" | ||
| ``` | ||
|
|
||
| **Command-line Flag:** | ||
| `--log.format <string>` (Note: some applications might use a different flag name like `--log_format`) | ||
| *Example:* `--log.format json` | ||
| *Default:* `"text"` | ||
| *Constant:* `FlagLogFormat` (value: "evolve.log.format", but often overridden by global app flags) | ||
|
|
||
| ### Log Trace (Stack Traces) | ||
|
|
||
| **Description:** | ||
| If true, enables the inclusion of stack traces in error logs. This can be very helpful for debugging issues by showing the call stack at the point of an error. | ||
|
|
||
| **YAML:** | ||
|
|
||
| ```yaml | ||
| log: | ||
| trace: false | ||
| ``` | ||
|
|
||
| **Command-line Flag:** | ||
| `--log.trace` (boolean, presence enables it; Note: some applications might use a different flag name like `--log_trace`) | ||
| *Example:* `--log.trace` | ||
| *Default:* `false` | ||
| *Constant:* `FlagLogTrace` (value: "evolve.log.trace", but often overridden by global app flags) | ||
|
|
||
| ## Signer Configuration (`signer`) | ||
|
|
||
| Settings related to the signing mechanism used by the node, particularly for aggregators that need to sign blocks. | ||
|
|
||
| **YAML Section:** | ||
|
|
||
| ```yaml | ||
| signer: | ||
| # ... signer configurations ... | ||
| ``` | ||
|
|
||
| ### Signer Type | ||
|
|
||
| **Description:** | ||
| Specifies the type of remote signer to use. Common options might include `file` (for key files) or `grpc` (for connecting to a remote signing service). | ||
|
|
||
| **YAML:** | ||
|
|
||
| ```yaml | ||
| signer: | ||
| signer_type: "file" | ||
| ``` | ||
|
|
||
| **Command-line Flag:** | ||
| `--evolve.signer.type <string>` | ||
| *Example:* `--evolve.signer.type grpc` | ||
| *Default:* (Depends on application, often "file" or none if not an aggregator) | ||
| *Constant:* `FlagSignerType` | ||
|
|
||
| ### Signer Path | ||
|
|
||
| **Description:** | ||
| The path to the signer file (if `signer_type` is `file`) or the address of the remote signer service (if `signer_type` is `grpc` or similar). | ||
|
|
||
| **YAML:** | ||
|
|
||
| ```yaml | ||
| signer: | ||
| signer_path: "/path/to/priv_validator_key.json" # For file signer | ||
| # signer_path: "localhost:9000" # For gRPC signer | ||
| ``` | ||
|
|
||
| **Command-line Flag:** | ||
| `--evolve.signer.path <string>` | ||
| *Example:* `--evolve.signer.path ./keys/mykey.pem` | ||
| *Default:* (Depends on application) | ||
| *Constant:* `FlagSignerPath` | ||
|
|
||
| ### Signer Passphrase | ||
|
|
||
| **Description:** | ||
| The passphrase required to decrypt or access the signer key, particularly if using a `file` signer and the key is encrypted, or if the aggregator mode is enabled and requires it. This flag is not directly a field in the `SignerConfig` struct but is used in conjunction with it. | ||
|
|
||
| **YAML:** | ||
| This is typically not stored in the YAML file for security reasons but provided via flag or environment variable. | ||
|
|
||
| **Command-line Flag:** | ||
| `--evolve.signer.passphrase <string>` | ||
| *Example:* `--evolve.signer.passphrase "mysecretpassphrase"` | ||
| *Default:* `""` (empty) | ||
| *Constant:* `FlagSignerPassphrase` | ||
| *Note:* Be cautious with providing passphrases directly on the command line in shared environments due to history logging. Environment variables or secure input methods are often preferred. |
Contributor
There was a problem hiding this comment.
The flag names in this configuration reference and throughout the new documentation guides appear to be incorrect. For example, --evolve.node.aggregator should be --rollkit.node.aggregator. All Evolve-specific flags should use the rollkit. prefix as defined in pkg/config/config.go. Please perform a global check and correction of these flag names across all new documentation files.
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
tac0turtle
force-pushed
the
marko/merge_docs
branch
from
0395de7 to
a7ec67a
Compare
tac0turtle
force-pushed
the
marko/merge_docs
branch
from
a7ec67a to
4353cda
Compare
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #2526 +/- ##
==========================================
- Coverage 73.72% 73.66% -0.06%
==========================================
Files 72 72
Lines 6713 6713
==========================================
- Hits 4949 4945 -4
- Misses 1364 1367 +3
- Partials 400 401 +1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
randygrok
approved these changes
Aug 6, 2025
alpe
added a commit
that referenced
this pull request
Aug 7, 2025
* main: fix: docs deployment (#2528) chore: merge docs repo into this repo (#2526) optimize: implement head index for BatchQueue.Next() to avoid O(n) slice re-slicing (#2519) build(deps): Bump github.com/rs/zerolog from 1.33.0 to 1.34.0 (#2525) chore: migrate from ipfs/go-log to zerolog across codebase (#2516) fix: proto inclusion (#2515) build(deps): Bump github.com/docker/docker from 28.2.2+incompatible to 28.3.3+incompatible in /test/docker-e2e in the go_modules group across 1 directory (#2503) refactor: replace Split in loops with more efficient SplitSeq (#2502) feat: expose ev-node P2P and RPC ports in docker compose (#2513) feat: create grpc execution environemnt (#2490)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Overview
merging docs into here in order to create a mono repo so its easier to keep things updated when we make changes here